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ABSTRACT 

This  paper  considers  progress  towards  establishing  a Multi- 
disciplinary Design  Optimisation  (MDO)  capability  for 
assessment  and  design.  Some  basic  questions  are  posed  and 
answered  on  the  basis  of  experience  gained  by  DERA  as  a 
result  of  participation  in  a series  of  recent  National  and 
International  projects  undertaken  in  partnership  with  UK  and 
European  industry  and  government  research  agencies.  Issues 
addressed  include  the  definition  of  MDO;  its  function  within 
concurrent  engineering;  the  role  of  product  models;  the 
definition  and  execution  of  the  MDO  process  under  user 
control;  the  use  of  trade-off  studies  for  requirements  capture; 
and  the  degree  to  which  MDO  can  support  detailed  design 
work.  The  need  for  the  adoption  of  standards  in  the  definition 
of  the  product  model  is  highlighted. 


INTRODUCTION 

Multi-disciplinary  design  optimisation  enables  the 
effectiveness  of  products  to  be  optimised  and  supports  trade- 
off studies  between  the  design  objectives  from  diverse 
disciplines.  The  MDO  process  is  intended  for  use  within  the 
context  of  a modern  engineering  design  environment,  which 
is  characterised  by  the  commercial  imperative  to  reduce  time 
cycles  and  costs.  These  commercial  pressures,  together  with 
the  immense  volume  of  design,  manufacturing  and 
maintenance  data  inherent  to  complex  modern  equipment, 
demand  a heavily  computerised  environment. 

Current  practice,  as  exemplified  by  Concurrent  Engineering 
(CE),  is  to  move  the  design  of  complex  equipment  away  from 
a process  involving  a sequence  of  specialist  departments  and 
to  emphasise  its  multidisciplinary  nature  through  the  use  of 
integrated  product  teams.  Both  the  structural  integrity  of 
engineering  products  and  the  demonstration  of  the 
performance  of  proposed  designs  are  increasingly  reliant  on 
the  use  of  computer  models  created  during  the  design  process. 
Although  the  software  tools  existing  within  individual 
disciplines  may  be  reasonably  mature,  the  challenge  is  now  to 
provide  the  tools  necessary  to  support  such  an  integrated 
approach. 
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The  scope  of  MDO  is  limited  to  the  design  of  products  based 
on  the  simulation  of  physical  objects  in  their  environment. 
The  use  of  multiple  simulations  is  a key  concept  of  MDO. 
This  may  involve  diverse  tools  such  as  fluid  flow  solvers  (to 
determine  local  and  overall  external  forces),  structural 
analysis  and  detail  stressing  (to  determine  structural 
deformations  and  internal  stresses),  electromagnetic  analysis 
(to  determine  radar  signatures  from  local  and  overall  returns 
from  incident  beams),  cost  modelling,  and  tools  for  design  for 
reliability.  The  physics  modelling  may  be  mathematical  or 
experimental  but  the  simulation  of  ‘human  interaction’ 
effects,  for  example  through  the  use  of  flight  simulators,  is 
excluded. 

At  a general  level,  when  considering  the  overall  mission 
performance  of  an  aircraft,  tools  exist  to  aid  the  conceptual 
design  of  both  military  and  civil  aircraft,  and  are  used  during 
the  early  stages  of  the  project.  Figure  1 shows  the  3 phases  of 
project  design  and  3 corresponding  levels  of  tools.  Although 
a fully  multidisciplinary  approach  is  adopted  at  the 
conceptual  design  stage  only  the  simplest,  Level  1,  empirical 
models  are  employed  to  approximate  the  physics  which 
influence  the  overall  design.  Currently  most  MDO 
applications,  for  use  in  the  preliminary  design  phases  of  a 
project,  are  based  on  major  simplifications  in  mathematical 
modelling  at  level  2,  such  as  beam  structural  models  or  panel 
methods  for  aerodynamics. 

The  objective  today  is  to  achieve  the  same  degree  of 
integration  with  Level  3,  state-of-the-art  analyses.  The 
limiting  factor  in  the  use  of  proven  models  of  this  type  is  the 
capacity  of  current  computation  technology.  Analyses  using 
computational  fluid  dynamics,  computational  electro- 
mechanics, or  detailed  finite  element  models  are  separately 
capable  of  pressing  computer  resources  to  the  limit,  and  this 
is  compounded  by  the  introduction  of  sensitivity  calculations 
and  optimisation.  With  the  continuing  advance  of 
computation  technology  it  can  be  expected  that  analysis 
methods  will  migrate  up  the  pyramid  shown  in  figure  1. 

DERA  has  for  many  years  been  involved  in  multi-disciplinary 
optimisation  in  two  areas;  (1)  using  semi-empirical,  Level  1, 
methods  for  concept  assessment  and  to  study  the  effect  of 
changes  in  operational  requirements,  through  the 
development  and  application  of  Multivariate  optimisation 
(MVO)l>2?  and  (2)  using  Finite  Element  methods  in 
structural  design,  including  linear  methods  for  aerodynamic 
analysis,  through  the  development  and  application  of  the 
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Fig  1 Project  phases  and  tools  for  multi  disciplinary  design 


STARS  system  3.  From  experience  gained  in  these  two  areas 
the  present  authors  embarked  in  1995  on  an  examination  of 
the  potential  and  means  for  MDO.  The  fundamental 
difference  of  this  MDO  work  from  the  earlier  work  has  been 
that  it  has  incorporated  higher  fidelity.  Level  2 or  3. 
modelling  in  at  least  two  disciplines.  Because  it  was  not  clear 
what  were  the  major  issues  and  potential  problems  in 
achieving  a viable  MDO,  a rap  id -prototyping  approach  was 
followed  initially.  Previous  work  defining  and  building  an 
MVO  system  had  shown  that  it  was  not  possible  to  predict  in 
advance  where  the  weakest  link  in  the  chain  would  occur,  so 
development  effort  could  have  been  misdirected  if  a rapid 
prototyping  approach  had  not  been  followed.  Subsequent 
work  has  comprised  a series  of  relatively  short-term  projects, 
funded  by  UK  government  military  and  civil  customers,  and 
the  Commission  of  the  European  Union.  All  the  projects  have 
had  a strong  industry  participation. 

In  the  next  section  of  the  paper  the  contribution  of  DERA  to  a 
series  of  projects  is  summarised.  Several  of  these  projects  are 
the  subject  of  separate  papers  at  the  RTO  AVT  Symposium 
on  Aerodynamic  Design  and  Optimisation  of  Flight  Vehicles, 
and  the  reader  is  referred  to  papers  13,  14  and  1 5 for  detail. 

Drawing  on  the  experience  gained  in  these  projects  the 
following  section  attempts  to  identify  the  issues  for 
implementation  of  an  MDO  process.  This  is  approached  via  a 
series  of  questions  and  answers.  The  paper  concludes  by 
identifying  the  prime  issues  and  some  next  steps  required  to 
progress  towards  providing  an  MDO  tool  that  can  be  more 
generally  used  for  air  vehicle  concept  design  and  assessment. 


CHRONOLOGY  OF  MDO  PROJECTS 
Wing  Aeroelastic  Optimisation 

The  GARTEUR  Action  Group  SM(AG21)  on  multi- 
disciplinary wing  design  (1995-1999)  covered  the  integration 
of  strength  and  aeroelastic  aspects  of  the  design  of  high 
aspect  ratio  wings  typical  of  modern  regional  transport 
aircraft,  as  illustrated  in  figure  2.  The  DERA  contribution  was 
based  on  the  use  of  the  in-house  structural  optimisation  code, 
STARS^  which,  like  several  others,  embodies  aeroelastics  as 
a tightly-coupled  functionality.  Both  the  aeroelastic 
predictions  and  design  strategies  to  come  out  of  the 
optimisation  have  been  compared  with  those  of  the  other 
partners  within  the  group.  While  several  European  companies 
had  long  had  the  capability  of  combining  aeroelastic  design 
with  basic  strength  requirements  within  the  context  of  what 
are  principally  structural  design  codes,  the  GARTEUR  Action 
Group  provided  a forum  for  the  validation  and  comparison  of 
the  capabilities  of  the  participants.  Such  comparison  was  felt 
to  be  important  since  experience  has  shown  that  significantly 
different  ‘solutions'  can  found  by  different  groups.  Unless 
analysis  codes  are  thoroughly  benchmarked  valid  conclusions 
on  the  relative  merits  of  these  codes  in  a design  and 
optimisation  environment  cannot  be  made. 


Figure  2 Regional  transport  aircraft  used  for  wing  aeroelastic  optimisation 


The  MPEST  project 

In  this  1 year  project  (1995-1996)  an  MDO  Prototype  for  the 
Evaluation  of  Software  Tools  (MPEST)  was  constructed  and 
demonstrated^.  Funded  by  the  UK  MOD  the  prototype  was 
assembled  by  British  Aerospace  Sowerby  Research  Centre, 
with  additional  contributions  from  DERA,  BAe  Airbus  and 
Rutherford  Appleton  Laboratory.  The  prime  aim  was  to 
assemble  software  for  the  key  functional  elements  of  an  MDO 
framework  and.  by  exercising  these  on  a simple  aerodynamic 
/ structural  optimisation  problem,  identify  priority  areas  for 


development.  Figure  3a  shows  the  framework  used.  A 2- 
dimensional  Fowler  flap  design  problem  was  used  with  the 
analysis  methods  being  deliberately  kept  simple;  a 2-d  panel 
code  for  aerodynamic  analysis  and  a simple  beam  model  for 
the  structural  analysis  of  the  trailing-edge  flap  track  (figure 
3b).  This  simple  technical  task  had  all  the  elements  required 
to  explore  MDO  issues.  The  framework  consisted  of  elements 
for  user-control,  optimisation  control,  geometry  generation, 
aerodynamic  and  structural  analyses,  and  a data  repository. 
The  process  by  which  an  optimum  solution  to  the  flap 
problem  was  generated  is  shown  in  figure  3c. 


Figure  3a.  MDO  framework  used  in  the  MPEST  project 


Shroud 


Figure  3b.  Geometry  of  flap  section  used  in  the  MPEST  project 
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Figure  3c.  MPEST  optimisation  process 


This  project  showed  the  value  of  geometric  parameterisation 
to  accelerate  re-design  and  the  need  for  a plug-and-play 
capability  for  the  software  elements.  The  importance  of 
process  control,  a user  interface  to  track  the  solution  of 
potentially  complex  problems  and  standards-based  data 
structures  were  clear.  The  issue  of  whether  MDO  should  be  a 
distributed  or  integrated  process  was  raised.  While  distributed 
processing  can  speed  analysis  and  hence  permit  more 
comprehensive  cross-discipline  modelling,  a single  process 
would  avoid  complexity  of  control. 

The  EU  MDO  project 

The  next  project,  on  the  Multi-disciplinary  Analysis  and 
Optimisation  of  Aerospace  Vehicles,  was  led  by  British 
Aerospace  Airbus  and  funded  by  the  European  Commission. 
It  comprised  research  on  civil  aircraft  wing  design  by  14 
partners.  This  two-year  European  project  (1996-1998) 
represented  a first  step  into  multidisciplinary  analysis  and 
design  optimisation  of  aerospace  vehicles  for  many  of  the 
partners.  The  application  selected  to  demonstrate  new 
capabilities  developed  during  the  project  was  based  on  the 
A3xx  concept  currently  under  development  by  the  Airbus 
partners.  A whole  aircraft  model  was  provided  for  aeroelastic 
and  controls  studies,  but  the  design  activity  was  focused  upon 
the  wing.  The  project  is  described  in  detail  by  All wright^ 
from  British  Aerospace,  who  led  the  project. 

All  partners  in  the  project  participated  in  the  definition  of  the 
research  tasks  and  then  separate  groups  were  responsible  for 
specialist  investigations.  The  project  was  supported  by  the 
software  infrastructure  group  with  participants  drawn  from 
each  of  the  research  task  groups.  The  final  stage  of  the 


activity  was  to  draw  together  the  lessons  learnt  from  the 
project  as  recommendations.  Further  progress  towards  a full 
MDO  capability  was  made,  with  the  major  advance  being  the 
introduction  of  aerodynamic  design  optimisation  and  the 
combination  of  aerodynamics  and  structural  design  to  reduce 
the  Direct  Operating  Cost  (DOC).  Some  consideration  was 
also  given  to  issues  of  aircraft  stability  and  control. 

Groupings  of  partners  within  the  project  analysed  a baseline 
configuration  and  examined  alternative  wing  design  aspects. 
This  served  both  to  ensure  that  corresponding  product 
variants  were  modelled  within  each  discipline  and  also  to 
reduce  the  requirement  for  problem-specific  data  flow 
between  disciplines.  The  issue  of  process  control  was  also 
addressed  with  a variety  of  approaches  being  investigated.  A 
range  of  approaches  was  also  evident  in  the  role  of  the 
optimiser,  with  some  frameworks  treating  it  as  just  another 
process  within  the  chain  and  others  allowing  the  optimiser  to 
control  the  whole  process.  These  areas  are  considered  in  more 
detail  below. 

Aerodynamic  and  Structural  design.  The  objective  of  the 
work  was  to  develop  and  demonstrate  a capability  for  the 
aerodynamic  and  structural  design  of  a wing  which  would 
minimise  the  direct  operating  cost  (DOC)  of  the  A3xx 
concept  aircraft.  The  majority  of  the  wing  optimisation  work 
used  a few  gross  wing  design  parameters  (area,  aspect  ratio, 
rear  spar  location,  sweep,  crank  thickness  and  tip  twist). 

A strong  need  was  perceived  to  use  familiar  legacy  codes 
within  a loose-coupled  modular  framework  that  enabled  the 
output  from  every  process  to  be  evaluated  before  proceeding. 
The  DERA-specific  work  introduced  multiple  flight 
conditions  into  the  optimisation.  This  task  illustrated  the  need 
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for  flexibility  within  an  MDO  process,  to  allow  the  user  to 
configure  the  optimisation  process  to  accommodate  multiple 
assessment  tools,  specific  to  each  problem. 

Product  models  and  TDMB.  The  complexity  of  the  data 
flow  that  links  the  disciplines  of  aerodynamics  and  structures, 
is  illustrated  in  figure  4.  This  starts  with  a requirements 
system,  which  is  assumed  to  be  external  to  the  MDO  system, 
in  which  some  freedom  is  assumed  to  exist  to  fine-tune  the 
relative  importance  of  various  aspects  of  performance.  An 
outline  concept  is  then  developed  as  a parameterised  product 
model.  This  is  followed  by  various  assessments,  here  shown 
as  aerodynamics  and  structures,  with  the  possibility  of 
making  detailed  shape  and  thickness  changes  for  a given 
configuration. 

Referring  to  figure  4 it  is  clear  that  large  amounts  of  data, 
which  may  well  be  stored  in  separate  databases,  must  be 
communicated  between  the  component  parts  of  the  MDO 
system.  The  key  issue  for  data  transfer  is  the  setting  of 
common  standards  for  the  interpretation  of  information  across 
disciplines.  For  MDO,  the  standards  must  cover  all  aspects  of 
product  geometry  definition  and  design  requirements, 
together  with  specific  discipline-based  data  that  reflects  the 
constraints  upon  the  design. 

During  the  early  meetings  of  the  MDO  project,  a series  of  key 
activities  were  decided  upon  which  defined  the  nature  of  the 
project.  One  was  to  adopt  the  BAe  program  TDMB^ 
Technical  Data  Modeller  and  Browser)  as  the  repository  for 
the  product  model  TDMB  provides  a text  editor  user 
interface  which  supports  a definition  of  data  objects.  It  can 
then  be  expanded  to  store  instance  data  capable  of 
representing  several  variants  of  the  product  together  with 
performance  data  derived  from  aerodynamic  and  structural 
analysis. 

A fully  parameterised  representation  of  the  aircraft 
configuration  was  developed,  with  tools  to  generate  the 
aerodynamic  data,  finite  element  models  and  aeroelastic 
models  used  for  performance  assessment.  This  data- 
representation  serves  the  project  by  providing  partners  with  a 
common  product  model  upon  which  design  studies  were 
based.  The  data  models  defined  in  TDMB  will  be  exportable 
to  the  STEP/EXPRESS  data  definition  language  to  enable 
future  migration  to  other  systems  which  conform  to  evolving 
standards  for  product  models.  The  wider  use  of  data  which 
conforms  to  the  STEP  standards^  is  an  important  element  of 
achieving  the  CALS  objective  of  ‘creating  data  once  and 
using  many  times’  through  the  product  life  cycle. 

The  use  of  a central  data  manager  and  browser  in  this  project 
was  shown  to  be  of  key  importance  to  the  success  of  the 
project  in  that  it  put  in  place  a single  product  model  from 
which  specific  contributing  analysis  models  could  be  derived. 

MDO  process  A major  factor  which  will  influence  the 
overall  success  of  any  MDO  implementation  is  the  approach 
adopted  to  the  co-ordination  and  scheduling  of  the  diverse 
range  of  activities  necessary  to  complete  a full  design  cycle. 
This  aspect  of  MDO  must  be  adequately  defined  in  the  early 


stages  of  the  development  process  in  order  to  draw  together 
the  different  disciplines  and  allow  concepts  to  be  explored. 

A framework  specification  document  was  written  by  a group 
of  partners  in  the  project  and  some  software  tools  were 
provided  for  evaluation.  These  included  tools  for  software 
version  management,  data  definition,  database  technology, 
process  definition,  process  execution  on  distributed  networks, 
data  visualisation  and  optimisation.  Several  alternative 
frameworks  were  employed  and  evaluated  against  the  user 
and  system  requirements  previously  developed.  The 
frameworks  assessed  included  commercial  MDO  frameworks 
and  toolsets,  a process-driven  Workflow  Management  tool 
and  Network  middleware.  The  frameworks  tended  to  operate 
with  a pre-defined  sequence  of  operations  and  failed  to 
provide  the  user  with  sufficient  flexibility  to  reconfigure  the 
process  during  the  early  exploratory  phases  of  a design  study. 
The  interactive  definition  of  a complex  process  is  a prime 
requirement  of  any  optimisation  framework. 

The  strength  of  a work  flow  management  tool  is  the 
traceability  and  control  it  offers,  whereby  only  approved 
users  may  initiate  processes  and  this  may  only  be  done  if  the 
input  data  has  not  been  invalidated  by  changes  by  an 
upstream  process.  Network  middleware  systems  enabled  the 
computer  resources  of  the  network  of  machines  to  be  utilised 
with  the  facility  that  one  may  expect  of  a single  machine,  but 
tended  to  require  user-intervention  and  were  weak  at  running 
chained  processes. 

As  might  have  been  expected  the  purpose-written  MDO 
frameworks  provided  the  most  flexible  integration  support 
but  did  not  necessarily  distinguish  the  process  support  aspects 
(including  the  registration  of  tools,  the  definition  of  process 
chains  and  their  execution)  from  data  management  (product 
models  and  requirements)  or  from  embedded  tools  (for  the 
visualisation  of  various  categories  of  data  or  optimisation 
functionality).  Further  development  is  needed  if  the 
frameworks  are  to  operate  in  a standards  driven  environment 
accessing  data  from  corporate  data  bases. 

The  role  of  the  optimiser  The  role  of  the  optimiser  was  also 
the  subject  of  slight  variation  within  the  various  partner 
frameworks.  At  the  simplest  level,  the  optimiser  calls  for 
function  evaluations,  possibly  including  gradients,  at  a 
sequence  of  design  points  and.  in  effect,  controls  the  process. 
As  the  function  evaluations  call  for  increasingly  time- 
consuming  analyses  with  complex  data  interactions  and, 
possibly,  requiring  user-intervention,  this  becomes  a less 
attractive  option. 

An  alternative  approach  is  still  to  start  the  design  cycle  with 
the  optimiser  initiating  a design  change,  but  to  return  control 
to  the  framework  for  the  performance  assessment  phase.  The 
optimiser  must  then  be  capable  of  being  restarted  once  the 
performance  assessment  is  complete.  In  software  terms,  the 
optimiser  may  then  appear  as  just  another  MDO  process,  to 
be  called  as  required,  but  its  controlling  role  within  the 
process  of  design  should  still  be  recognised. 


12-6 


Figure  4.  Data  flow  for  multi-disciplinary  design,  showing  software  tools 
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The  FRONTIER  project 

The  FRONTIER  project^  (1996-1999)  was  led  by  British 
Aerospace  Military  Aircraft  and  funded  by  the  European 
Commission.  Although  FRONTIER  was  a relatively  small 
project,  it  had  the  widest  scope  in  that  it  considered  design 
against  multiple  objectives.  The  project  partners  consisted  of 
universities  who,  in  the  main,  acted  as  suppliers  of  new 
technology  and  industrial  partners  who  provided  user  trials 
relevant  to  their  industry  sector.  It  comprised  research  to 
develop  and  evaluate  a framework  for  multi-disciplinary 
optimisation,  with  multi-criterion  decision  making  (MCDM) 
software  to  capture  customer  preferences,  across  a variety  of 
mechanical  engineering  applications.  The  project  also 
examined  the  capture  of  requirements.  It  is  almost  inevitable 
that  the  initial  formulation  of  an  MDO  problem  will  not 
automatically  lead  to  the  required  product,  since  the  impact  of 
constraints  and  the  balance  of  conflicting  requirements  will 
not  be  fully  understood  at  the  outset.  The  Pareto  frontier 
approach  provides  the  user  with  visibility  of  potential  design 
trade-offs  and  an  ability  to  choose  the  relative  importance 
placed  upon  multiple  design  objectives.  Clearly,  if  cost  were 
a criterion,  this  leads  to  a cost/performance  assessment  which 
is  a key  input  to  any  requirement  capture  process. 

In  this  project  DERA  evaluated  the  software  tools  developed 
for  this  purpose  by  other  members  of  the  FRONTIER 
Consortium,  to  explore  combat  aircraft  wing  design  from  a 
performance  perspective.  From  multi-disciplinary 
aerodynamic  and  structural  analyses,  results  for  aircraft  range 
(related  to  fuel  volume,  aircraft  mass  and  drag)  and 
supersonic  sustained  manoeuvre  performance  (related  to 
aerodynamic  drag)  were  derived.  Figure  5,  taken  from  the 


paper  by  Fenwick  and  Harris8,  shows  that  an  envelope  curve, 
the  Pareto  frontier,  may  drawn  to  encompass  the  performance 
results  obtained  for  the  family  of  wings  of  fixed  planform 
which  covered  a range  of  wing  thickness  and  spanwise 
thickness  taper. 

Requirement  capture  for  military  aircraft  The  user  trial 
conducted  by  DERA  in  partnership  with  BAe  was  based  on 
the  design  of  a military  wing  and  sought  to  achieve  an 
acceptable  compromise  between  aircraft  range  and  turn 
performance.  In  this  instance  the  aerodynamic  model  was 
taken  as  the  master  model,  but  in  the  longer  term  it  would  be 
expected  that  both  the  aerodynamics  and  structures  models 
would  be  derived  from  a common  product  model.  The 
approach  taken  is  a multilevel  Pareto-optimisation  in  which 
the  wing  thicknesses  (wing-box  depth)  at  various  stations  are 
used  as  top-level  variables  linking  the  structures  and 
aerodynamic  disciplines.  The  structural  optimisation 
determines  the  sizes  of  the  composite  covers  and  sub- 
structure for  each  geometry,  while  the  aerodynamic 
optimisation  modifies  the  airfoil  shape  to  maximise  a 
weighted  sum  of  lift  to  drag  ratios  corresponding  to  a 
supersonic  turn  condition  and  transonic  cruise. 

The  supersonic  turn  rate  and  transonic  range  shown  in  figure 
5 are  then  calculated  from  the  drag,  mass  and  fuel  volumes. 
Each  curve  corresponds  to  a given  spanwise  thickness 
distribution  but  with  the  aerodynamic  shape  optimised  to  give 
differing  levels  of  transonic  to  supersonic  performance.  In 
general  the  thicker  wings  give  greater  range  due  to  their 
increased  fuel  capacity,  but  ultimately  (case  9)  higher  drag 
will  reduce  the  range. 
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The  Pareto  frontier  itself,  indicated  in  grey  in  figure  5. 
bounds  the  region  in  which  it  is  possible  to  design  products  to 
meet  the  conflicting  requirements.  The  best  products  have 
performance  characteristics  which  lie  close  to  the  ‘top-right' 
part  of  the  boundary.  From  here  it  is  only  possible  to  improve 
one  characteristic  at  the  expense  of  the  other. 

The  use  of  genetic  algorithms  has  been  assessed  as  a method 
of  achieving  convergence  to  the  boundary  of  the  region. 
Typically  such  direct  search  methods  require  many  function 
evaluations,  each  one  of  which  calls  a full  structural 
optimisation  for  mass  as  well  as  an  aerodynamic  minimisation 
of  drag  for  two  flight  conditions.  The  fact  that  these  tasks  are 
computationally  intensive  makes  the  activity  appropriate  for 
high-performance  computing  in  the  longer  term,  but  to  reduce 
the  computing  costs  during  the  FRONTIER  project,  response 
surfaces  were  calculated  for  the  wing  mass  and  drag.  The 
Pareto  frontier  could  then  be  calculated  on  the  basis  of  the 
cheaper  response  surface  information  rather  than  from  further 
calls  to  the  underlying  design  software.  This  enabled 
sufficient  computing  resources  to  be  devoted  to  the 
assessment  of  genetic  algorithms  within  the  Pareto  frontier 
approach,  and  to  evaluating  the  MCDM  software  tool  for 
deducing  the  weightings  attached  to  the  various  design 
objectives  from  customer  preferences.  This  aspect  of  the 
project  was  of  particular  interest  as  it  extended  the  scope  of 
MDO  so  that  it  assists  with  identification  of  the  design 
requirements  that  the  product  should  meet.  The  FRONTIER 
software  provided  a graphic  demonstration  of  the  ability  to 
choose  rapidly  an  appropriate  mix  of  fighter  and  bomber 
requirements. 

The  ENHANCE  project 

The  ongoing  project  ENHANCE  (1999-2002),  funded  by  the 
Commission  of  the  EU,  is  addressing  issues  in  Concurrent 
Engineering.  This  large  European  project  (38  MEURO)  has 
53  partners  drawn  from  the  aeronautical  industry  and  research 
community.  The  main  objectives  are  to  define  new  common 
ways  of  working,  applicable  from  the  initial  design  phase 
onwards,  to  propose  a set  of  operational  tools  and  to  validate 
the  new  approach  through  a full  range  of  industrial 
experiments.  Central  to  the  project  is  a set  of  13 
“COMMONs"  each  of  which  will  define  a common  way  of 
working  within  a given  domain  for  engineering.  It  is  planned 
to  develop  a set  of  Concurrent  Engineering  processes  which 
will  be  adopted  by  all  the  parties.  Implementation  of  these 
processes  is  expected  to  lead  to  large  reductions  in  vehicle 
development  timescales  and  costs,  and  to  more  effective  and 
efficient  utilisation  of  common  exchange  standards,  leading 
to  increased  competitiveness. 

DERA  is  contributing  to  the  Common  Scientific  Calculation 
(COSCAL)  element  of  the  Product  Engineering  section  of  the 
project.  Interfacing  and  integration  of  structural  and 
aerodynamic  analysis  methods  within  a common  data 
exchange  environment  are  being  defined  and  implemented. 


DISCUSSION 

Each  of  the  projects  summarised  above  has  given  a different 
perspective  on  MDO.  In  this  section  the  discussions  and 
conclusions  from  the  individual  projects  are  brought  together 
and  the  major  issues  identified.  To  do  this  some  basic 
questions  need  to  be  answered: 

• Why  do  we  need  MDO? 

• What  are  the  necessary  elements  for  MDO? 

• How  can  these  elements  be  pul  in  place? 

• What  are  the  obstacles  to  be  overcome? 

• Who  needs  to  take  action? 

Why  do  we  need  MDO? 

Many  answers  have  already  been  given  to  this  question,  but 
to  summarise: 

The  military  customer  requires  affordable  and  effective 
integrated  air-vehicle  systems,  while  industry  aims  to  produce 
an  air-vehicle  system  that  meets  customer  requirements  and 
produces  a profit  for  its  shareholders.  To  achieve  these  ends 
the  military  requirements  and  the  potential  solutions  must  be 
brought  together  with  high  fidelity  of  simulation,  to  reduce 
the  cost  and  risk  of  a project.  Industry  needs  a process  to 
evolve  concepts  by  bringing  to  bear  quickly  and  effectively 
the  full  spectrum  of  their  engineering  design  capabilities.  The 
military  customer  needs  a process  to  allow  operational 
requirements  to  be  evolved  so  that  balanced  concepts  result 
for  the  warfighter.  Thus  responsiveness  to  evolving 
requirements  is  common  to  both  parties.  Reduced  time  for  a 
design  or  assessment  cycle  allows  more  cycles  to  be 
completed  in  a given  time,  and  a better  product  (cheaper  for 
the  same  performance  or  higher  performance  for  the  same 
cost)  to  be  defined.  In  the  UK  there  is  an  increasing  degree  of 
overlap  in  the  design  and  assessment  processes  because  of  the 
move  to  joint  Industry  / MOD  project  teams. 

What  are  the  necessary  elements  for  MDO? 

The  following  list  captures  all  the  elements  required.  They  are 
listed  in  order  of  increasing  difficulty  of  satisfaction  across 
the  potentially  wide  spectrum  of  users. 

• Robust,  compatible  analysis  codes 

• Proven  procedure  for  optimisation 

• Data  structure 

• Requirements  capture 

• Framework  architecture  and  hardware 

• Control 

Each  of  these  is  considered  in  detail  in  responding  to  the  next 
question. 

How  can  these  elements  be  put  in  place? 


Analysis  codes  The  characteristics  of  any  analysis  code  to  be 
used  for  assessment,  design  or  optimisation  must  be 
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thoroughly  evaluated  for  the  regime  in  which  it  is  to  be 
applied.  The  range  of  applicability  needs  to  be  defined.  When 
used  in  an  optimisation  process  any  shortcomings  in  the 
modelling  of  physics  within  an  analysis  method  can 
potentially  lead  to  erroneous  conclusions  and  hence  invalidate 
the  process.  A standard  interface  to  pre-processing  (e.g. 
geometry  input)  and  post-processing  (e.g.  flow  field  analysis 
and  visualisation)  is  required.  Although  this  can  be  achieved 
for  legacy  codes  by  writing  a software  ‘wrapper’ , it  is 
preferable  to  have  a standard  interface  built  into  the  analysis 
software. 

Optimisation  Flexibility  is  required  in  the  means  by  which 
an  ‘optimum ’ can  be  defined.  For  optimisation  within  a local 
area  of  design  space  or  for  a we  11 -understood  problem 
gradient  / line-search  methods  are  most  effective.  When 
exploring  a large  region  of  design  space  the  genetic-algorithm 
(GA)  type  of  method  has  the  advantage  of  being  able  to  avoid 
local  optima.  Thus  for  mathematical  optimisation  in  a new 
problem  use  of  a variety  of  methods  is  likely  to  be  preferable, 
if  the  potentially  large  computational  requirement  of  a GA 
element  can  be  accepted.  Response  surface  methods  provide  a 
means  of  reducing  the  computational  requirements  while 
capturing  many  of  the  prime  features  of  the  design  space. 

In  considering  real  engineering  problems  it  is  generally  found 
that  the  definition  of  constraints  is  a critical  element  of  the 
problem  definition.  While  methods  for  unconstrained 
optimisation  are  mature  and  can  produce  well  defined  optima, 
this  is  not  the  case  for  constrained  optimisation  methods.  In 
particular  few  gradient-based  methods  can  produce  well- 
converged  solutions  for  problems  with  a large  number  of  non- 
linear constraints.  With  the  GA  type  of  method  constraints 
can  be  handled  by  including  in  the  objective  function  a 
penalty  term  made  up  of  the  sum  of  the  magnitudes  of  the 
constraint  violations,  but  this  approach  can  produce  poor 
convergence.  For  engineering  design  in  industry,  visibility  of 
the  design  space  is  an  important  requirement  so  that  trade-off 
studies  may  be  made  to  guide  a decision  on  the  ‘optimum’. 
Thus  a series  of  analyses  and  sub-discipline  optimisations 
may  be  preferred  to  a total  optimisation.  For  an  MDO  system 
to  be  of  general  use  it  is  necessary  to  provide  all  of  these 
options. 

Data  Structure  To  allow  re-use  of  an  MDO  method  data 
describing  the  product  (i.e.  aerospace  vehicle)  needs  to  be 
defined  in  a ‘standard’  form  so  that  analysis  programmes  can 
retrieve  and  deposit  the  necessary  parameters.  The  data 
describing  the  vehicle  ‘object’  is  not  just  geometric  but  will 
also  cover  the  physical  properties  and  performance  of  the 
product.  To  provide  the  widest  possible  commonality  the 
product  should  be  defined  using  an  International  standard 
with  an  associated  data  description  language  (e.g.  STEP  with 
the  EXPRESS  language).  Because  there  are  many  ways  in 
which  an  object  can  be  described  the  choice  of  the  model  to 
characterise  a product  needs  to  be  made  by  the  prime 
customers  for  an  MDO  system,  i.e.  industry  (for  design, 
development  and  manufacture)  and  government  procurement 
agencies  (for  requirements  definition  and  project  assessment). 


With  the  current  trend  to  integrated  product  teams  the 
responsibility  for  model  definition  falls  naturally  to  industry. 

Parameterisation  of  geometry  is  a particularly  important 
aspect  of  a product  model.  Historically  different  methods  of 
parameterisation  have  been  used  for  each  engineering 
discipline  (e.g.  finite  elements  for  structures,  point  data  or  bi- 
cubic patches  for  CFD,  and  CAD  for  manufacture).  The 
requirement  for  a product  model  is  thus  to  provide  the 
reference  detailed  description  of  the  object  in  such  a form  that 
the  necessary  information  can  be  readily  extracted  for  all 
disciplines.  A potential  difficulty  arises  from  the  fact  that 
geometry  parameterisation  can  be  combined  with  geometric 
design  rules  if  full  advantage  is  taken  of  the  capability 
available  within  modern  CAD  tools  for  implementing 
knowledge-based  systems.  As  a result  a product  model  can 
become  proprietary,  holding  the  accumulated  knowledge  of 
specialist  designers.  This  type  of  product  model  could  not 
therefore  be  released  to  the  general  R&D  community  so  it  is 
essential  to  separate  the  two  functions. 

Requirements  capture  Problems  that  are  likely  to  be  tackled 
with  MDO  are  typically  sufficiently  complex  that  they  have 
no  unique  definition.  Requirements  can  be  translated  into 
alternative  combinations  of  optimisation  objectives,  or 
constraints,  or  bounds  on  design  variables,  and  can  be  applied 
at  low  or  high-level  in  the  MDO  process.  The  capture  of 
requirements  for  an  MDO  problem  needs  to  be 
comprehensive  as  the  omission  of  ‘obvious’  or  ‘trivial’ 
requirements  can  result  in  unrealistic  solutions.  It  is  important 
to  distinguish  between  requirements  that  are  genuine 
constraints  (e.g.  to  prevent  overlap  between  components  in  a 
vehicle)  and  design  ‘rules’  derived  from  established  design 
practice  that  potentially  limit  the  available  design  space.  For 
design  in  industry  the  latter  encapsulate  best  practice  and  thus 
they  are  often  proprietary  in  nature,  giving  the  company  a 
competitive  edge  in  the  market  place.  It  should  be  noted  that 
the  imposition  of  constraints  of  this  nature  removes  some 
degree  of  design  freedom  and  thus  can  potentially  limit 
performance. 

Framework  architecture  and  hardware.  Many  alternative 
software  architectures  have  been  examined  by  workers  in  the 
MDO  field.  The  most  suitable  approach  will  be  determined 
by  the  particular  problem  being  addressed  and  the  computing 
resource  available.  While  it  is  not  possible  to  be  more 
prescriptive  than  this,  all  frameworks  should  comprise 
elements  with  identifiably  separate  functions,  and  be 
implemented  in  an  object-oriented  form,  so  that  the 
framework  can  be  readily  adapted  as  the  design  problem 
evolves  (and  typically  grows  in  size).  The  framework  needs 
to  be  suitable  for  implementation  on  networked  computers, 
partly  to  link  specialised  analysis  groups  but  also  to  allow 
parallelisation  of  any  optimisation  elements. 

Control  From  an  industry  standpoint  the  weapon  system 
designer  wishes  to  make  design  judgements  across  a large 
number  of  issues,  including  commercial  ones.  Thus  he  will 
emphasise  man-in-the-loop  control  of  the  MDO  process,  so 
that  the  process  may  be  altered  to  provide  the  information  on 
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the  specific  design  trades  he  requires.  At  the  other  extreme  an 
automatic  large-scale  optimisation  could  be  defined  that 
required  no  user  interaction  within  the  process.  Experience 
indicates  that  results  from  a single  optimisation  of  this  type 
are  of  little  use.  Knowledge  of  the  design  space  in  the  vicinity 
of  the  “optimum"  is  essential  before  any  judgement  on  the 
worth  of  a design  can  be  reached.  Thus  a series  of 
optimisations  is  necessary,  probably  with  systematic  changes 
to  constraints  and  / or  objective  functions.  A user  interface  is 
therefore  required  which  supports  process  definition  and 
execution,  and  allows  iteration  without  a man-in-the-loop 
(although,  initially,  user  intervention  is  vital).  Analysis 
methods  must  be  automated  and  results  displayed  in  a multi- 
disciplinary format.  Experience  from  the  MDO  project 
recounted  above  indicates  that  the  control  element  should  also 
include  the  definition  of  the  role  of  the  optimiser:  is  it  in 
control  of  the  process  or  controlled  by  the  process? 

What  are  the  obstacles  to  be  overcome? 

From  the  above  discussion  based  on  the  experience  of 
participation  in  MDO  projects  in  the  past  5 years,  five  issues 
need  to  be  addressed  to  progress  MDO  from  a research-based 
activity  to  one  that  will  be  of  real  value  to  industry  and 
procurement  agencies: 

• Control  of  a distributed  MDO  process  - who  is  in  charge 
of  the  problem  solution? 

• Interactive  definition  of  the  MDO  process  to  match 
problem  requirements 

• Definition  of  a product  model  for  general  use 

• User  confidence  in  results  from  analysis  codes 

• Audit  of  overall  optimum  by  specialists  from  disciplines 

Two  other  areas  are  important  for  improving  the  effectiveness 
of  MDO.  but  progress  is  likely  to  be  evolutionary  and  driven 
in  part  by  advances  in  computation  technology: 

• Optimisation  methods  and  strategy 

• Geometric  parameterisation 

Who  needs  to  take  action? 

Considering  the  first  five  issues  listed  above  it  is  clear  that  the 
lead  responsibility  for  their  resolution  rests  largely  with 
industry,  as  they  are  central  to  the  concept  definition  process. 
In  the  UK  this  responsibility  may  devolve  to  a joint  industry  / 
military  project  team.  Research  agencies  will  continue  to 
develop  new  technologies  and  demonstrate  them.  They  can 
assist  industry  in  the  technology  insertion  process  for  the 
selected  tools.  The  last  two  issues  are  likely  to  continue  to  be 
addressed  by  research  projects  developing  new  approaches 
and  improved  methods  for  the  integration  of  disciplines.  It 
will  be  essential  for  this  work  to  be  focused  on  realistic 
engineering  problems  generated  in  partnership  with  industry. 


CONCLUSIONS 

A number  of  developments  relevant  to  the  practical  use  of 
MDO  have  been  identified  by  reference  to  a sequence  of 
collaborative  research  activities  in  which  DERA  has 
participated.  It  is  believed  essential  for  the  credibility  of  an 
MDO  process  that  it  should  be  able  to  accommodate  the 
design  processes  used  by  engineers  within  industry  to  assess 
and  validate  their  products. 

Seven  areas  have  been  identified  that  need  to  be  addressed  to 
advance  MDO.  Of  these  the  prime  factor  currently  limiting 
further  development  of  MDO  is  the  lack  of  a product  model 
to  act  as  a standard  for  data  accessed  across  disciplines.  To 
achieve  this  it  is  essential  that  the  data  storage  function  be 
decoupled  from  rule  storage  (expert  knowledge)  function  that 
co-exist  in  some  CAD- based  product  models,  because  of  the 
potentially  proprietary  nature  of  design  rules.  It  is  desirable  to 
use  STEP  to  standardise  the  form  in  which  product  data  is 
shared  and  exchanged  amongst  processes. 

A good  framework  for  MDO  that  provides  a flexible  user 
interface  for  the  definition,  execution  and  monitoring  of 
MDO  processes  is  essential  and  further  development  of  clear 
architectures  for  such  software  is  still  required.  While 
conceptual  design  tools  are  often  close-coupled,  loosely 
coupled  systems  appear  to  be  more  appropriate  to  MDO  in 
that  they  assist  the  verification  of  results  by  specialists.  Some 
loss  in  process  efficiency  or  even  the  generation  of  sub- 
optimal  designs  is  acceptable  provided  the  design  process  is 
understood  and  credible. 

The  future  role  of  Research  Agencies  in  advancing  MDO  is 
seen  as  developing  and  validating  new  technology  for 
integrating  analyses  and  optimisation,  and  assisting  industry 
and  procurement  agencies  in  the  insertion  of  the  resulting 
tools  into  their  design  and  assessment  processes. 
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